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Abstract 


JSMARTS  (Joint  Simulation,  Modeling  for  Material  Acquisition,  Requirements,  Training  and 
Support),  or  Joint  SMARRT  (Simulation  and  Modeling  for  Acquisition,  Requirements, 
Rehearsal  and  Training)  represents  a  new  concept  for  DND  (Department  of  National 
Defence),  it  is  conceptualized  as  a  vision  of  M&S  (Modeling  &  Simulation)  at  the  Enterprise 
level,  led  by  ADM(Mat).  In  an  effort  to  reduce  the  technical  risk  associated  with  networking 
simulation  stakeholders  at  various  levels  of  the  DND  Enterprise,  a  WAN  (Wide  Area 
Network)  distributed  simulation  was  executed,  regrouping  in  the  same  virtual  environment 
(Synthetic  Environment)  the  Government  of  Canada,  Industry  and  Academia.  In  this  HLA 
(High  Level  Architecture)  Federation,  the  national  Canarie  Network  was  selected  as  the 
common,  non-dedicated,  unclassified,  VPN-encrypted  network  procuring  connectivity 
between  Federates.  While  CAE  Inc.  was  providing  CGF  (Computer  Generated  Forces), 

DRDC  Ottawa’s  FFSE  Section  was  providing  a  UAV  (Uninhabited  Aerial  Vehicle)  simulator, 
a  NATO  STANAG  4586  compliant  Ground  Control  Station,  both  supported  by  the  Joint 
Simulation  Network.  (JSIMNET:  FFSE’s  persistent  simulation  capability).  Finally,  Carleton 
University  provided  a  NTS  (Networked  Tactical  Simulator)  CH  146  Griffon  helicopter 
human-in-the-loop  simulator.  DAR  (Director  Aerospace  Requirements)  graciously  provided 
pilots,  whereas  the  UAV  aircrew  was  provided  by  CFEC  (Canadian  Forces  Experimentation 
Centre).  To  reduce  the  FEDEP  (Federation  Development  and  Execution  Process) 
development  time  to  a  bare  minimum,  different  FOMs  (Federation  Object  Models)  and 
different  RTIs  (Run  Time  Infrastructures)  were  used  but  bridged  by  a  remapping  middleware 
tool.  Finally,  since  a  common  SE  (Synthetic  Environment)  tool,  STRIVE,  existed  amongst 
participants,  it  was  used  across  all  organizations,  further  simplifying  development  time. 

CHI 46  NTS  pilots  and  UAV  Aircrew  were  engaged  in  3  separate  experimental  conditions 
while  human  performance  measurements  were  collected.  This  document  provides  a  technical 
summary  of  the  technical  issues  directly  related  in  the  successful  execution  of  the  present 
Exercise. 

This  study  has  demonstrated  a  successful  case  of  interoperable  HLA-based  distributed 
simulation  across  Government  of  Canada,  Industry  and  Academia.  Further,  this  study  suggests 
that  harmonization,  coherence  and  alignment  with  international  standards,  international 
protocols  as  well  as  common  tools  ensured  quick  reusability  of  existing  simulation 
capabilities  in  the  participating  organizations,  for  maximum  interoperability. 
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I 


Resume 


Le  projet  JSMARTS  (simulation  et  modelisation  conjointes  pour  l’acquisition  du  materiel,  les 
besoins,  l’entrainement  et  le  soutien),  ou  SMARRT  (simulation  et  modelisation  pour 
l’acquisition,  les  besoins,  la  repetition  et  l’entrainement)  conjoint,  represente  un  nouveau 
concept  pour  le  MDN  (ministere  de  la  Defense  nationale),  il  est  conceptualise  sous  forme 
d’une  vision  de  modelisation  et  de  simulation  (M  et  S)  au  niveau  de  l’entreprise,  menee  par 
SMA(Mat).  Dans  le  but  de  diminuer  le  risque  technique  relie  a  la  simulation  de  reseautage  des 
parties  interessees  a  divers  niveaux  de  l’entreprise  du  MDN,  on  a  effectue  une  simulation 
repartie  a  reseau  de  zone  etendue  (WAN)  qui  regroupait  le  meme  environnement  virtuel 
(environnement  synthetique)  du  gouvemement  du  Canada,  de  l’industrie  et  du  monde 
universitaire.  Dans  cette  federation  d’ architecture  evoluee  (HLA),  on  a  retenu  le  reseau 
national  Canarie  comme  reseau  prive  virtuel  encode  commun,  non  specialise  et  non  protege, 
qui  assurait  la  connectivity  entre  les  organisations  federees.  La  firme  CAE  Inc.  a  foumi  les 
forces  generees  par  ordinateur  (CGF),  la  section  ESFF  du  RDDC  Ottawa  a  fourni  un 
simulateur  d’engin  telepilote  et  le  poste  de  controle  au  sol  connexe  conforme  a  la  STAN  AG 
4586  de  l’OTAN,  les  deux  soutenus  par  le  reseau  de  simulation  conjoint  (JSIMNET  :  capacity 
de  simulation  constante  du  ESFF).  Enfin,  l’etablissement  Carleton  University  a  fourni  un 
simulateur  tactique  reseaute  (NTS)  ou  Thumain  fait  partie  de  la  boucle  pour  Thelicoptere  CH 
146  Griffon.  Le  Directeur  -  Besoins  en  ressources  aerospatiales  (DBRA)  a  obligeamment 
foumi  les  pilotes,  tandis  que  l’equipage  de  conduite  de  Tengin  telepilote  a  ete  fourni  par  le 
Centre  d’ experimentation  des  Forces  Canadiennes  (CEFC).  Afin  de  reduire  le  plus  possible  le 
temps  d’ elaboration  du  FEDEP  (elaboration  de  federation  et  processus  d’ execution),  on  a 
utilise  differents  modeles  objets  de  federation  (FOM)  et  differentes  infrastmctures  de  temps 
d’execution  (RTI)  que  Ton  a  relies  au  moyen  d’un  intergiciel  de  remappage.  Finalement, 
puisqu’un  outil  commun  d’ environnement  synthetique  (STRIVE)  existait  deja  parmi  les 
participants,  on  a  utilise  cet  outil  pour  toutes  les  organisations,  ce  qui  a  simplifle  encore  plus 
le  temps  de  developpement.  Les  pilotes  du  NTS  du  CH146  et  T  equipage  de  conduite  de 
Tengin  telepilote  ont  participe  a  trois  experiences  distinctes  pendant  lesquelles  on  mesurait  les 
performances  humaines.  Le  present  document  fournit  un  resume  technique  des  questions 
techniques  directement  reliees  a  la  reussite  du  present  exercice. 

La  presente  etude  a  demontre  un  cas  reussi  de  simulation  repartie  a  architecture  evoluee 
interoperable  entre  le  gouvemement  du  Canada,  Tindustrie  et  le  monde  universitaire.  De  plus, 
cette  etude  laisse  croire  que  T harmonisation,  la  coherence  et  la  conformity  avec  les  normes  et 
les  protocoles  internationaux,  de  meme  que  Tutilisation  d’outils  communs  sont  susceptibles 
d’ assurer  une  reutilisabilite  rapide  des  capacity  s  de  simulation  existantes  dans  les 
organisations  participates,  de  maniere  a  assurer  une  interoperability  maximale. 
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Executive  summary 


While  distributed  simulations  have  taken  place  in  Canada  since  at  least  the  1990s,  using 
mostly  the  DIS  (Distributed  Interactive  Simulation)  /  IEEE  1278  standard  or  HLA  (High 
Level  Architecture)  /IEEE  1516,  very  few  have  involved  the  Government  of  Canada, 
Academia  and  Industry  in  a  joint  exercise.  JSMARTS,  or  Joint  SMARRT  represents  a  new 
vision  for  DND,  a  vision  of  M&S  at  the  Enterprise  level,  led  by  ADM(Mat). 

In  an  effort  to  reduce  the  technical  risk  associated  with  networking  simulation  stakeholders  at 
various  levels  of  the  DND  Enterprise,  a  WAN  (Wide  Area  Network)  distributed  simulation 
was  executed,  regrouping  in  the  same  virtual  environment  (Synthetic  Environment)  the 
Government  of  Canada,  Industry  and  Academia.  In  this  HLA  Federation,  the  national  Canarie 
Network  was  selected  as  the  common  and  preferred  non-dedicated,  unclassified,  VPN- 
encrypted  network  procuring  connectivity  between  Federates.  The  participants  are, 

CAE  Inc.:  provided  CGF  (Computer  Generated  Forces) 

-  FFSE/DRDC  Ottawa:  provided  a  UAV  Simulator,  a  NATO  STANAG  4586 

compliant  Ground  Control  Station,  both  supported  by  the  Joint  Simulation  Network 
(JSIMNET) 

Carleton  University:  provided  an  NTS  (Networked  Tactical  Simulator)  CH  146 
Griffon  Helicopter  human-in-the-loop  simulator 
DAR  (Director  Aerospace  Requirements):  provided  Chi 46  pilots 
CFEC  (Canadian  Forces  Experimentation  Centre):  provided  the  UAV  aircrew 
To  reduce  the  FEDEP  (Federation  Development  and  Execution  Process)  development  time  to 
a  bare  minimum,  different  FOMs  (Federation  Object  Models)  and  different  RTIs  (Run  Time 
Infrastructures)  were  used  but  bridged  by  a  remapping  middleware  tool.  Finally,  since  a 
common  SE  (Synthetic  Environment)  tool,  STRIVE,  existed  amongst  participants,  it  was  used 
across  all  organizations,  further  simplifying  development  time.  CHI 46  NTS  pilots  and  UAV 
Aircrew  were  engaged  in  3  separate  experimental  conditions  while  human  performance 
measurements  were  collected.  The  repeated  measures  experimental  schema  is  described 
below: 

-  Scenario  1:  A  sole  CH-146  Griffon  Helicopter  operating  on  its  own 

-  Scenario  2:  A  CH-146  and  a  UAV  operating  with  a  third  party  comms  link. 

-  Scenario  3:  A  CH  146  and  a  UAV  with  a  direct  data  link  in  addition  to  the  comms  link. 

This  document  provides  a  summary  of  the  technical  issues  directly  related  in  the  successful 
execution  of  the  present  Exercise.  This  study  has  demonstrated  a  successful  case  of  an 
interoperable  HLA  based  distributed  simulation  across  GOC,  Industry  and  Academia.  Further, 
this  study  suggests  that  harmonization,  coherence  and  alignment  with  international  standards, 
international  protocols  as  well  as  common  tools  ensured  quick  reusability  of  existing 
simulation  capabilities  in  the  participating  organizations,  for  maximum  interoperability. 


B.  Kim,  R.  Johnson,  R.  Youssef,  A.L.Vallerand,  C.  Herdman,  M.  Gamble,  R.  Lavoie,  D.  Kurts  and  K. 
Gladstone.  2005.  JSMARTS  Initiative:  Advanced  Distributed  Simulation  across  the  Government  of 
Canada,  Academia  and  Industry  -  Technical  Description.  DRDC  Ottawa  TM  2005-101.  Defence  R&D 
Canada  -  Ottawa. 
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Sommaire 


Meme  si  des  simulation  reparties  ont  eu  lieu  au  Canada  depuis  au  moins  les  annees  1990,  a 
l’aide  principalement  de  simulations  interactives  reparties  (DIS)  de  norme  IEEE  1278  ou 
d’ architectures  evoluees  (HLA)  de  norme  IEEE  1516,  il  y  a  eu  tres  peu  de  simulations  dans  un 
exercice  conjoint  entre  le  gouvemement  du  Canada,  le  monde  universitaire  et  l’industrie.  Le 
JSMARTS,  ou  SMARRT  conjoint,  represente  une  nouvelle  vision  pour  le  MDN,  une  vision 
de  M  et  S  au  niveau  de  l’entreprise,  menee  par  SMA(Mat).  Dans  le  but  de  diminuer  le  risque 
technique  relie  a  la  simulation  de  reseautage  des  parties  interessees  a  divers  niveaux  de 
l’entreprise  du  MDN,  on  a  effectue  une  simulation  repartie  a  reseau  de  zone  etendue  (WAN) 
qui  regroupait  le  meme  environnement  virtuel  (environnement  synthetique)  du  gouvemement 
du  Canada,  de  l’industrie  et  du  monde  universitaire.  Dans  cette  federation  d’ architecture 
evoluee  (HLA),  on  a  retenu  le  reseau  national  Canarie  comme  reseau  prive  virtuel  encode 
commun,  non  specialise  et  non  protege,  qui  assurait  la  connectivity  entre  les  organisations 
federees.  Les  organisations  participantes  sont : 

la  firme  CAE  Inc.  qui  a  fourni  les  forces  generees  par  ordinateur  (CGF) 

la  section  ESFF  du  RDDC  Ottawa  qui  a  fourni  un  simulateur  d’engin  telepilote  et  le 
poste  de  controle  au  sol  connexe  conforme  a  la  STANAG  4586  de  l’OTAN,  les  deux 
soutenus  par  le  reseau  de  simulation  conjoint  (JSIMNET) 

l’etablissement  Carleton  University  qui  a  foumi  un  simulateur  tactique  reseaute 
(NTS)  ou  l’humain  fait  partie  de  la  boucle  pour  l’helicoptere  CH  146  Griffon. 

le  Directeur  -  Besoins  en  ressources  aerospatiales  (DBRA)  qui  a  obligeamment 
foumi  les  pilotes 

le  Centre  d’ experimentation  des  Forces  Canadiennes  (CEFC)  qui  a  fourni  T  equipage 
de  conduite  de  l’engin  telepilote. 

Afin  de  reduire  le  plus  possible  le  temps  d’ elaboration  du  FEDEP  (elaboration  de  federation  et 
processus  d’execution)  on  a  utilise  differents  modeles  objets  de  federation  (FOM)  et 
differentes  infrastmctures  de  temps  d’execution  (RTI)  que  l’on  a  relies  au  moyen  d’un 
intergiciel  de  remappage.  Finalement,  puisqu’un  outil  commun  d’ environnement  synthetique 
(STRIVE)  existait  deja  parmi  les  participants,  on  a  utilise  cet  outil  pour  toutes  les 
organisations,  ce  qui  a  simplifie  encore  plus  le  temps  de  developpement.  Les  pilotes  du  NTS 
du  CHI 46  et  V equipage  de  conduite  de  l’engin  telepilote  ont  participe  a  trois  experiences 
distinctes  pendant  lesquelles  on  mesurait  les  performances  humaines.  Le  cadre  experimental 
de  mesures  repetees  est  decrit  ci-apres: 

-  Scenario  1  :  Un  seul  helicoptere  CH-146  Griffon  utilise  isolement. 

-  Scenario  2  :  Un  CH-146  et  un  engin  telepilote  utilises  avec  une  liaison  commune  avec  une 
tierce  partie. 

-  Scenario  3  :  Un  CH  146  et  un  engin  telepilote  utilises  avec  une  liaison  de  donnees  directe  en 
plus  de  la  liaison  commune. 


IV 


DRDC  Ottawa  TM  2005-  101 


Le  present  document  fournit  un  sommaire  des  questions  techniques  directement  reliees  a  la 
reussite  du  present  exercice.  Cette  etude  a  demontre  un  cas  reussi  de  simulation  repartie  a 
architecture  evoluee  interoperable  entre  le  gouvernement  du  Canada,  l’industrie  et  le  monde 
universitaire.  De  plus,  cette  etude  laisse  croire  que  1’ harmonisation,  la  coherence  et  la 
conformite  avec  les  normes  et  les  protocoles  internationaux,  de  meme  que  l’utilisation  d’outils 
communs  sont  susceptibles  d’ assurer  une  reutilisabilite  rapide  des  capacites  de  simulation 
existantes  dans  les  organisations  participantes,  de  maniere  a  assurer  une  interoperabilite 
maximale. 
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1 .  Overview 


In  June  2004  the  Canadian  DND  Assistant  Deputy  Minister  (Materiel)  proposed  an 
overarching  “Joint  SMARTS”  (JSMARTS)  vision  whereby  the  development  and  use 
of  M&S  knowledge,  international  M&S  standards  and  M&S  interoperability  would 
exist  not  only  in  DND  but  across  GOC,  Academia,  and  Industry.  In  accordance  with 
this  vision,  DRDC  Ottawa,  Carleton  University  and  CAE  Inc.  conducted  a  JSMARTS 
interoperability  experiment  whereby  the  Uninhabited  Air  Vehicle  Research  Test  Bed 
(UAV  RTB)  at  DRDC  Ottawa  was  linked  with  a  CH146  Griffon  Networked  Tactical 
Simulator  (NTS)  at  Carleton  University.  CAE  Inc.  provided  constructive  assets  to 
facilitate  interoperability  between  the  two  sites  and  to  advance  the  architecture  and 
core  capabilities  of  the  NTS  system  at  Carleton  University.  This  JSMARTS  initiative 
has  been  termed  the  “UAV-NTS  SE  Experiment”  (attached  CD  contains  DND- 
approved  short  video  clips  in  both  languages). 

This  initiative  was  put  in  place  to  investigate  use  of  M&S  within  the  JSMARTS 
context,  or  M&S  at  the  Enterprise  level.  It  was  also  designed  to  explore  several 
concepts  such  as: 

1 .  The  concept  of  Rapid  implementation  of  Distributed  Simulation:  is  it  possible 
to  develop  and  execute  an  HLA  federation  within  a  few  weeks,  or  does  it 
always  take  months  or  more? 

2.  Is  it  possible  to  use  such  an  initiative  as  an  opportunity  to  engage  other 
participants  in  DND,  OGDs  (including  Public  Security/Safety  communities), 
Industry,  Academia  on  discussions  related  to  increasing  the  “critical  mass  of 
simulationists”  in  Canada  through  presentation  of  effort  and  results,  i.e.:  can 
we  augment  the  number  of  interoperable  M&S  capabilities  of  Government, 
Academia  and  Industry? 

3.  Is  it  conceivable  to  create  a  persistent  ability  to  easily  employ  M&S  in 
Government,  Academia  and  Industry  to  jointly  explore/analyze  new 
Capabilities? 


2.  Objective 


The  JSMARTS  initiative  was  not  about  simply  connecting  simulators  together  once 
and  dismantling  them  immediately  after  the  occasion.  It  was  assembled  to  accomplish 
sets  of  three  specific  objectives:  interoperability  objectives,  technical  objectives,  and 
human  performance  objectives.  In  terms  of  overall  M&S  interoperability,  the 
objective  was  to  execute  a  distributed  HLA  simulation  with  GOC,  Academia,  and 
Industry  partners  in  a  few  weeks  at  little  or  no  cost.  The  technical  objectives  were 
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obviously  dependent  on  the  interoperability  objective:  all  technical  objectives  were 
aimed  at  reducing  SE  development  time  to  a  minimum  while  executing  the  Federation 
using  the  international  HLA  Standard  protocol.  Finally,  there  was  human  performance 
objective  as  CH146  pilots  and  UAV  aircrew  involved  in  the  experiment  were  tested 
and  measured  against  a  set  of  criteria  in  each  phase  of  the  experimental  design 
focused  on  Network-Centric  Warfare. 


3.  Technical  Issues  related  to  Connecting  Simulation 
Capabilities  for  Distributed  Mission  Ops 

3.1  Simulation  Capabilities 


Two  distinct  simulation  capabilities  formed  the  main  HLA-based  federates  taking  part 
in  the  distributed  exercise,  namely  the  UAV  Research  Test  Bed  (UAV  RTB)  housed 
at  FFSE’s  facility  at  DRDC-Ottawa  and  the  Griffon  Helicopter  simulator  housed  at 
Carleton  University’s  ACE  lab.  Figure  1  gives  an  overview  of  the  set-up  of  this 
distributed  federation.  Within  the  UAV  RTB  at  DRDC-Ottawa,  a  number  of  other 
CGF  federates  were  generated  and  maintained  by  the  STRIVE  application. 
Technically,  there  are  many  ways  to  ensure  connectivity  across  any  federates  in  a 
distributed  federation;  the  communities  can  use: 

1 .  A  proprietary  or  self-owned  telecommunication  line; 

2.  A  leased  dedicated  telecommunication  Line; 

3.  A  leased  (non-dedicated)  line; 

4.  Leased  bandwidth  on  a  (non-dedicated)  line; 

5.  A  free  national  infrastructure  line; 

6.  Wireless  telecommunication. 
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Carle  ton  U  NTS 
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Figure  1:  Graphical  representation  of  JSMARTS  Distributed  Simulation  layout  across  three 
participants:  DRDC  Ottawa,  CAE  Inc.  and  Carleton  University 


3.2  Distributed  Simulation  Network 

Using  a  telecommunication  line  from  a  free  national  infrastructure  asset  appealed  to 
all  participants  as  the  fastest  technique  toward  establishing  connectivity  quickly,  with 
no  procurement  or  contracting  involved,  though  it  did  not  appear  to  have  been  fully 
documented  in  a  Canadian  M&S  context.  Procuring  a  line  or  bandwidth  meant  time 
and  costs  and  commitment  to  that  schedule,  which  is  an  activity  that  would  have 
pushed  the  team  beyond  its  4  week  objective. 


3.3  Common  SE  TOOL 

A  search  for  a  common  SE  tool  was  performed  as  a  technique  to  simplify 
development  and  data  correlation  time.  Though  other  tools  could  have  been  used  by 
one  or  two  of  the  present  participants,  only  one  such  tool  appeared  common  to  all,  as 
it  had  been  regularly  used  by  the  participants  and  all  had  experience  on  it;  STRIVE 
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was  selected  as  the  common  SE  tool  and  agreed  upon  as  a  means  to  smartly  manage 
this  particular  initiative. 


3.4  FEDEP  Process,  FOM  and  RTI 

In  early  stage,  it  was  discovered  that  each  proposed  JSMARTS  federate  was  mapped 
to  different  FOMs.  While  it  had  been  agreed  to  tentatively  “show  leadership”  in  the 
community  by  remapping  federates  to  the  latest  standard  “Military”  FOM,  the 
forthcoming  SISO  Standard  “Real  Time  Platform  Reference-  Federation  Object 
Model  2.0”  (RPR-FOM  2.0;  www.sisostds.orgj,  this  activity  also  required  time  and 
human  resources  involvement:  i.e.:  development  time.  The  situation  was  further 
complicated  by  the  discovery  that  different  Run  Time  Infrastructure  (RTI)  were 
presently  associated  with  the  respective  federates.  The  UAV  RTB  employed  the 
STRIVE  FOM  along  with  the  CAE  RTI,  while  the  Griffon  simulator  used  the  RPR- 
FOM  1.0  along  with  the  “DMSO  RTI”  (now  referred  to  as  the  HLA  1.3  NG  v.6; 
www.dmso.mil).  Clearly,  this  situation  appeared  to  be  requiring  more  time  and 
greater  costs  involved  than  anticipated.  Clearly  one  of  the  objectives,  to  be  able  to 
execute  in  4  weeks,  was  in  line  with  being  unrealizable. 


3.5  Technical  solutions 

The  Defence  community  is  accustomed  to  purchasing  or  leasing  its  own 
telecommunications  network  for  a  particular  Experiment  or  SE  trial.  However,  there 
are  other  networks,  such  as  national  infrastructure  assets  that  are  presently  available  to 
the  community,  like  the  national  CANARIE  Network.  The  CANARIE  Network  was 
created  to  facilitate  the  development  of  Canada’s  communications  infrastructure  and 
to  stimulate  next  generation  products,  applications,  and  services.  As  a  national  optical 
Internet  research  and  education  network,  it  represents  the  Canadian  equivalent  to 
Internet  2,  coast-to-coast. 

The  CANARIE  Network  interconnects  provincial  research  networks,  Universities, 
Research  centres,  Government  Research  laboratories,  schools,  and  other  sites,  both 
with  each  other  and  with  international  peer  networks,  through  a  series  of  point-to- 
point  optical  wavelengths,  most  of  which  are  provisioned  at  OC-192  (10  Gbps) 
speeds.  The  CANARIE  Network  is  also  the  back  up  network  to  the  Internet  for  the 
DRENET,  the  ADM(S&T)  accredited  experimental  unclassified  network  connecting 
all  the  DRDC  Labs  across  the  Nation.  By  altering  the  configurations  of  our  PIX 
Firewalls,  we  were  able  to  end  up  with  the  following  network  configuration:  a  non- 
dedicated  ,  unclassified,  VPN-encrypted  (as  Virtual  Private  network  capability  is  built 
-in  the  Pix  Firewall)  network.  Using  VPNs  was  important  and  convenient.  It  enabled 
the  other  sites  to  behave  like  “enclaves”  or  extensions  to  our  simulation  capability,  the 
JSIMNET  (this  is  entirely  analogous  to  using  VPN  to  remotely  tunnel  in  to  work 
email  and  work  shared  drives,  with  encryption).  Since  that  network  is  a  robust  and  fast 
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network,  tests  were  performed  to  confirm  the  short  enough  latency  times  between 
sites,  prior  to  any  trials.  Latencies  were  on  average  below  144  milliseconds,  well 
below  the  threshold  where  SMEs  (Subject  Matter  Experts)  of  virtual  simulations 
indicate  that  human-in-the-loop  simulations  could  start  to  be  affected  by  a  poor 
latency  between  action  and  reaction  (about  350  ms;  Gamble- Vallerand,  March  2004 
personal  communication).  Further,  this  approach  to  connectivity  is  fully  consistent 
with  the  “Security  procedures,  rules  and  regulations  stated  in  “JSIMNET  Security 
guidelines  for  NON-DRENET  Connections”  (Skinner  &  Vallerand,  2005). 

The  concept  of  performing  distributed  simulation  with  different  FOMs  was  rejected. 
We  had  already  been  in  a  position  to  collect  data  in  such  a  situation  and  error 
messages  continuously  stated  that  object  attributes  could  not  be  found  ,  due  to  errors 
in  mapping.  Though  it  had  not  been  tested  and  reported  in  the  Canadian  literature, 
colleagues  at  Carleton  University  had  been  experimenting  with  a  FOM  Gateway 
known  as  “Genesa  or  STRIVE-RTI  connect”  a  COTS  tool  from  CAE  Inc.  Running 
such  a  tool  was  designed  to  provide  the  linkage/re-mapping  of  these  specific  attributes 
within  the  FOMs  during  the  exercises.  Further,  this  tool  was  also  designed  to 
accommodate  different  RTIs.  This  experiment  was  therefore  an  excellent  opportunity 
to  determine  whether  distributed  simulation  can  take  place  with  different  FOMs  and 
different  RTIs.  CAE’s  STRIVE-RTI  connect  is  a  next  generation  network 
interconnection  system  that  provides  multi-protocol  network  simulation  data  routing 
between  simulation  systems. 

Genesa/STRIVE-RTI  connect  is  designed  to 

1.  Provide  FOM  adaptability  and  FOM  filtering,  granting  data  exchange  between 
simulation  hosts  using  different  FOMs; 

2.  Provide  existing  systems  with  new  network  capabilities,  thus  increasing  the 
number  of  cooperative  heterogeneous  systems; 

3.  Act  as  a  multi-protocol-based  network  node,  natively  providing  interface  to 
standard  protocols  such  as  DIS,  HLA-1.3  and  IEEE-1516. 

It  also  appears  as  though  creating  an  interface  to  any  other  protocol  using  the  API  that 
is  provided  with  the  tool  can  easily  extend  connectivity  features  of  STRIVE-RTI 
connect.  A  description  of  the  system  architecture  is  shown  below  in  Fig  2. 
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Figure  2:  System  Architecture. 

JSimNet  -  Carleton  ACE  Lalos 
Sirmulotion  Network  Architecture 


Figure  3:  Network  Architecture  of  the  JSMARTS  Distributed  Simulation  layout  across  GOC, 
Industry  and  Academia. 
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4.  FFSE’s  Persistent  Simulation  Network  and 
Computer Infrastructure 


Using  FFSE’s  persistent  simulation  capability,  the  JSIMNET,  as  a  starting  point,  the 
JSMARTS  synthetic  environment  work  was  initiated  by  networking  a  certain  number 
of  computers  together,  into  dedicated  functions.  Most  of  these  computers  were 
employed  during  simulation  execution  on  any  particular  mission.  Of  these, 
approximately  twelve  computers  were  used  to  take  part  in  the  HLA  federation,  and  the 
others  were  used  for  distributing  data  streams  to  the  observation  labs  (i.e.:  Multi- 
Media  Lab  used  for  Live  Demonstrations).  Figure  4  shows  the  various  PCs  involved 
in  the  synthetic  environment  for  JSMARTS.  Figure  5  also  shows  the  internal 
components  to  the  RTB  (Research  Test  Bed). 
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-All  internal  boxes  represent  individual  PCs 

-A  total  of  31  PCs  were  used  during  the  ALIX  synthetic  environment  work 
-PC  names  and  specifications  are  listed  in  Table  1 
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Figure  4:  Detailed  Network  Diagram  for  JSMARTS  SE  at  FFSE,  showing  the  UAV  Research  Test 
Bed  1  (ROC),  UAV  RTB  2  (LARE),  Streaming  servers,  C2  element,  CFEC  remote  Ops,  Observation 

site,  Support  Player  comms. 
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Figure  5:  Internal  Components  of  RTB-1 


The  table  below  shows  the  roles  and  names  of  the  PCs  that  were  used  in  the 
JSMARTS  SE  work.  All  were  “off-the-shelf’  personal  computers:  either  desktops  or 
rack-mounted  except  for  one  laptop  running  the  command  and  control  personal 
computer  system  (explained  below).  All  machines  used  similar  computing  power,  i.e. 
known  as  Pentium  Zeon  1.7  GHz  with  1GB  RAM  up  to  a  Pentium  Zeon  2.4GHz  with 
2  GB  RAM. 


PC  Name 

Role 

Location 

Software 

UAV1  Strive 

Experiment  Manager 

UAV  lab  Room  228 

CAE  Strive 

UAV1  Sensor 

IR/EO  Sensor  Modelling 

UAV  lab  Room  228 

CAE  Turret  Simulation 

UAV1  Visual 

Sensor  Image  Generation 

UAV  lab  Room  228 

CAE  Medallion- S 

UAV1  RAP 

RTI  Data  Recording  and  Playback 

UAV  lab  Room  228 

CAE  RAP 

UAV1  Comms 

HLA  Communications  Systems 

UAV  lab  Room  228 

CAE  Voice  Encoding  Software 

GCS1  AVO 

UAV  air  vehicle  operator  station 

UAV  lab  Room  228 

CDL  VCS-4586  Apache  Server,  VLC  for 
Sensor  repeat  to  MPO 

GCS1 MPO 

UAV  mission  payload  operator 
station 

UAV  lab  Room  228 

CDL  VCS-4586  Apache  Server  for  GCS 
repeater 

GCS2 MPO 

Streaming  sensor  view  from  GCS 1 

ACCES  lab  Rm  222 

CDL  VCS-4586  Apache  Server  for  GCS 
repeater 

FFSE-ML03 

RTB  1  Crew  Camera  and  Video 

Server 

UAV  lab  Room  228 

Helix  server,  Real  Producer 

FFSE-ML04 

RTB  2  Crew  Camera  and  Video 

Server 

ACCES  lab  Rm  222 

Helix  server,  Real  Producer 

FFSE-DS20 

Composite  Voice  Capture  and  Audio 
Server 

UAV  lab  Room  228 

Helix  server,  Real  Producer 

FFSE-ACCS1 

RTB  1  Crew  Camera  View 

ACCES  lab  Rm  222 

HTML  viewer  +  VLC  for  video  stream 

FFSE-ACCS2 

RTB  2  Crew  Camera  View  +  GCS 
map  repeater 

ACCES  lab  Rm  222 

HTML  viewer 

+  Real  Player  for  video  stream 

FFSE-DS1 1 

Crew  Camera  View  from  Carleton 

ACCES  lab  Rm  222 

HTML  viewer  +  Real  Media  +  VLC  for 
video  stream 

FFSE-DS05 

Streamed  Voice  Receiver 

ACCES  lab  Rm  222 

HTML  viewer  +  Real  Player  for  audio 
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5.  Griffon  Helicopter  Simulation  at  Carleton 
University 

5.1  General  Overview 

The  flight  simulator  at  Carleton  University  is  a  customized  version  of  a  Networked 
Tactical  Simulator  (NTS)  developed  as  a  result  of  the  TAMSS  (Tactical  Aviation 
Mission  Systems  Simulation)  TDP  initiative,  through  funding  provided  by  the 
Department  of  Nation  Defence  (DND).  As  with  similar  NTS  systems,  the  Carleton 
NTS  represents  the  flight  deck,  mission  equipment,  and  physical  structure  of  the  CH- 
146  Griffon  helicopter  flown  by  DND.  The  Carleton  simulator  includes  both  out-the- 
window  (OTW)  and  Helmet  Mounted  Display  (HMD)  capabilities.  Additionally,  the 
simulator  supports  the  creation  of  synthetic  environments  and  scenario  creation  via  a 
collection  of  Commercial-Off-The-Shelf  (COTS)  software  tools. 

The  Carleton  NTS  is  unique  in  that  it  includes  experimental  and  data  collection 
capabilities.  These  experimental  capabilities  allow  a  user  to  create  visual  and  auditory 
events  that  can  be  inserted  into  a  mission.  The  data  collection  capabilities  enable  an 
experimenter  to  examine  over  100  logged  measures  in  analyzing  the  performance, 
workload,  and  situation  awareness  of  the  crew  operating  the  simulator. 


Figure  6  -  Carleton  University  NTS  Architecture  Overview 
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The  Carleton  NTS  consists  of  six  PCs,  running  the  Windows  2000  Professional 
operating  system.  Three  of  the  PCs  are  used  for  image  generation  (IG1,  IG2,  and 
IG3)  and  simultaneously  project  onto  three  8’  x  6’  screens,  providing  the  pilot  with  a 
near  180-degree  horizontal  and  40-degree  vertical  view.  Two  PCs  (INSTR1, 
INSTR2)  are  used  for  simulation  of  the  flight  model  and  instrumentation.  INSTR1  is 
responsible  for  running  the  helicopter  flight  model  (HELISIM),  simulating  the 
avionics,  and  for  driving  the  pilot  instrument  panel.  INSTR2  is  responsible  for  the 
operation  of  the  CDUs.  The  INSTR1  PC  also  hosts  the  custom  data  collection 
software  used  in  the  Carleton  experiments.  Finally,  the  sixth  PC,  the 
Experimenter/Operator  Station  (EOS),  is  responsible  for  overall  system  control, 
including  mission  loading  and  unloading.  This  PC  also  hosts  the  scenario  generation 
software  and  a  Stealth  viewer.  The  simulator  includes  an  ASTi  Digital  Audio 
Communications  System  (DACS)  that  supports  simulation  of  cockpit  voice 
communication  as  well  as  voice  communication  between  the  pilot  and  console 
operator.  Data  transfer  between  the  various  modules  occurs  via  one  of  three  modes. 
High  volume  data,  such  as  that  between  the  flight  model  software  and  scene 
generator,  uses  UDP  communications.  Communications  between  the  avionics 
simulation,  the  pilot  instrument  panels  and  the  CDU  infrastructure  is  via  high-level 
architecture  (HLA).  HLA  is  also  used  to  interface  the  simulator  to  external  systems. 
Finally,  shared  memory  is  used  for  communications  between  the  CDU  and  the  CDU 
Proxy,  which  facilitates  integration  of  the  non-HLA  native  CDU  simulation  into  the 
NTS  federation.  Figures  6  and  7  provide  a  general  overview  of  the  hardware, 
functionality,  and  communications  infrastructure  of  the  Carleton  NTS. 


Figure  7  -  Carleton  University  NTS  Hardware  Overview 
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5.2  Software  Overview 


The  Carleton  NTS  software  consists  of  several  Commercial  Off-the-Shelf  (COTS) 
Software  packages  integrated  by  custom  control,  communications,  and  experimental 
software.  The  primary  COTS  products  used  and  their  function  within  the  Carleton 
system  are  as  follows: 

Vega.  Vega,  a  product  from  Multigen-Paradigm  is  the  COTS  tool  used  to  render  the 
Out  the  Window  (OTW)  or  through  the  HMD  external  scene.  Vega’s  strength  is  that 
it  is  able  to  render  complex  geometries  in  real-time.  It  is  a  key  component  in 
achieving  visual  realism  in  the  simulation.  It  is  ultimately  based  on  the  OpenGL  2D 
and  3D  graphics  application  programming  interface  (API). 

Vega  uses  Openflight  (a  3D  file  format)  models  of  both  the  terrain  database  and  scene 
objects  to  render  the  scene.  These  entities  are  configured  into  the  Vega  application 
using  the  LynX  graphical  interface.  This  graphical  interface  is  used  to  create  Vega 
application  definition  files  (.adf  files).  These  files  describe  both  graphical  and 
platform  related  details  of  the  Vega  application.  Vega  renders  the  outside  scene  based 
on  the  graphical  objects  defined  in  the  .adf  files  and  a  given  “eye”  point  determined 
by  the  aircraft  position  and/or  head  position. 

Vega  also  includes  a  development  API  that  enables  a  user  to  customize  Vega 
functionality  for  specific  applications.  For  example,  this  API  is  used  in  the  Carleton 
system  to  generate  HUD  information  and  symbology.  Vega  software  callbacks  are 
used  to  superimpose  the  HUD  information  on  the  Vega  scene  as  seen  through  Night 
Vision  Goggles  (NVGs).  The  API  has  also  been  used  to  extend  Vega  capabilities  to 
handle  visual  experiment  events  generated  through  the  experimental  software. 

HELISIM.  Helisim,  from  eNGENUITY  Technologies,  Inc,  is  a  software  package 
used  to  provide  the  flight  model.  HELISIM  mimics  the  performance  of  a  rotary-wing 
aircraft  by  tuning  parameters  such  as  weight  and  balance,  propulsion  and  rotor 
characteristics,  and  instrumentation,  thus  enabling  the  simulator  to  closely  represent 
the  flight  dynamics  of  the  CH-146  Griffon.  HELISIM  accepts  inputs  from  the 
collective,  cyclic  and  pedals  of  the  simulator  and  using  the  defined  flight  model, 
updates  aircraft  position  (i.e.,  latitude,  longitude,  and  altitude),  aircraft  heading,  pitch, 
and  roll  as  well  as  several  other  flight  and  instrumentation  values. 

An  important  feature  of  HELISIM  is  an  API  that  allows  for  real-time  control  of 
various  aircraft  parameters.  This  is  an  extremely  important  feature  for 
experimentation.  Using  these  HELISIM  features,  the  Carleton  lab  has  developed  a 
capability  to  freeze  specific  instrumentation  (e.g.,  aircraft  heading,  radar  altimeter, 
etc.).  Pilots'  situational  awareness  of  their  cockpit  systems  is  measured  using  the 
freezing  capability  (e.g.,  did  the  pilot  notice  the  frozen  instrumentation,  how  long  did 
it  take  for  them  to  notice  and  react  to  the  frozen  instrumentation).  The  Carleton  lab 
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has  also  used  the  HELISIM  API  to  develop  a  capability  to  measure  the  control  of 
aircraft  position  and  orientation  based  on  an  ADS-33  attitude  recovery  task. 

STAGE.  STAGE  is  the  acronym  for  Scenario,  Toolkit  and  Generation  Environment. 
It  is  a  software  tool  used  to  create  complex  tactical  scenarios.  STAGE  provides  a 
graphical  user  interface  in  which  to  enter  information  into  a  tactical  database.  This 
database  then  generates  the  real-time  tactical  scenario.  STAGE  also  displays  the  real¬ 
time  positions  of  entities  in  the  scenario  as  it  is  run  on  its  situation  display. 

STAGE  is  used  to  add  “entities”  to  the  simulated  mission  scenarios.  This  STAGE 
entity  information  is  sent  to  Vega,  which  renders  the  STAGE  entities  in  the  external 
scene  in  the  appropriate  position.  The  level  at  which  the  pilot  detects  the  STAGE 
entities  during  the  mission  can  be  used  to  gauge  the  pilot’s  level  of  situational 
awareness. 

STAGE  can  be  run  in  one  of  two  modes  -  with  HLA  enabled  or  disabled.  When  HLA 
is  enabled,  STAGE  becomes  the  HLA  gateway  for  the  entire  system  and  can  be  used 
to  send  the  STAGE  entity  (including  Ownship)  information  to  external  agencies. 

When  the  STAGE  HLA  interface  is  not  enabled,  STAGE  communicates  only  with 
local  simulator  components. 

STEALTH.  The  MAK  Stealth  viewer  is  a  3D  visualization  tool  that  extends  the 
console  operator's  viewpoint  of  the  simulated  environment  beyond  the  fixed  point  of 
the  pilot  to  anywhere  in  the  simulated  world.  Stealth  enables  the  console  operator  to 
attach  to  other  entities  in  the  simulated  environment  to  see  the  world  through  their 
eyes.  Stealth  receives  its  information  on  entity  position  from  STAGE  using  the  HLA 
interface. 

5.3  Modifications  to  Support  JSMARTS  Experiment 

A  number  of  modifications  were  made  to  the  Carleton  NTS  in  order  to  support  the 
participation  in  the  JSMARTS  experiment.  These  modifications  were  undertaken  to 
ensure  a  proper  correlation  between  the  synthetic  environments  represented  on  each  of 
the  JSMARTS  participant  simulator  platforms,  thus  promoting  a  “fair  fight”  between 
live  participants  and  Computer  Generated  Forces  (CGF).  The  following  sections 
summarize  the  modifications  made  to  the  Carleton  NTS  in  order  to  facilitate 
participation  in  the  JSMARTS  experiment: 

5.3.1  Integration  of  CAE  Medallion-S  Image  Generation  System 

The  baseline  Image  Generation  (IG)  system  of  the  Carleton  NTS  was 
upgraded  to  a  CAE  Medallion-S  IG  software  running  on  COTS  computer 
hardware.  This  was  achieved  through  the  addition  of  four  rack-mounted  PCs, 
each  equipped  with  dual  3.0  GHz  Pentium  IV  processors,  1  GB  of  RAM  and 
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an  ATI  Radeon  9800  graphics  card.  Three  of  the  PCs  were  configured  as 
Medallion-S  OTW  visual  channels.  The  fourth  PC  was  configured  as  a 
Medallion-S  Mission  Information  Function  (MIF)  platform.  The  MIF 
functionality  was  used  to  compute  Height  Above  Terrain  (HAT)  in  order  to 
support  the  requirements  of  the  HELISIM  aerodynamic  model. 

The  integration  of  the  Medallion-S  IG  also  involved  the  development  of  a 
software  proxy  application  (IGProxy)  that  was  used  to  mediate  between  the 
Interface  Control  Document  (ICD)  specification  for  Medallion-S  and  the 
HELISIM-based  host  simulation. 

5.3.2  Federating  the  Carleton  NTS  with  the  JSMARTS  Federation 

A  STRIVE  plugin  was  developed  to  facilitate  the  federating  of  the  NTS  with 
the  JSMARTS  federation.  This  plugin  was  configured  to  receive  host  export 
information  from  HELISIM  (i.e.,  aircraft  Time,  Space,  Position  Information 
(TSPI))  and  represent  the  Carleton  NTS  as  a  simulation  entity  within  the 
JSMARTS  HLA  federation.  This  plugin  also  provided  an  interface  to 
HELISIM  that  allowed  the  Carleton  NTS  to  comply  with  JSMARTS 
federation  simulation  management  interactions,  such  as  «  Pause/Freeze  »  and 
«  Start/Resume  ».  The  support  for  these  interactions  was  important  in  order  to 
coordinate  federation  simulation  assets. 
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6.  Data  records  from  the  RTB  at  DRDC  Ottawa 


A  comprehensive  data  set  was  gathered  during  the  experiment,  including  all  entity 
motion,  STANAG  4586  message  data  (including  commanded  and  actual  positions  of 
the  UAV  and  camera  sensors),  voice  communications,  video  footage,  snapshots  of  the 
Global  Command  and  Control  Station  recognized  maritime  picture  and  daily  crew 
questionnaires. 


The  following  sections  discuss  and  provide  examples  of  the  quantitative  data 
recorded.  The  audio  and  video  files  are  in  the  attached  CD,  and  identified  by 
filenames,  which  include  the  date,  mission  and  time. 

6.1  Kinematic  data 

The  RTB  system  has  the  capability  to  record  missions,  by  storing  all  HLA  data  from 
the  run-time  infrastructure.  This  allows  playback  of  the  mission,  but  also  allows 
decoding  for  data  such  as  position,  attitude,  velocity,  and  acceleration  of  all  STRIVE 
entities,  including  the  UAV.  After  decoding,  data  associated  with  each  STRIVE 
entity  is  time-stamped  and  recorded  into  a  single  file  as  in  Figure  8.  The  first  line  of 
the  Record  and  Playback  (RAP)  file  contains  a  semicolon-separated  list  describing  (in 
text)  the  contents  of  each  field  in  each  subsequent  line.  These  files  will  be  referred  to 
as  RAP  data  files  herein.  All  fields  and  their  associated  data-type  contained  in  the 
RAP  files  are  listed  in  Figure  9. 


AbsoluteTimeStamp  ClassType  AccelerationVector.mXAcceleration  AccelerationVector.mY Acceleration 

AccelerationV  ector.mZ  Acceleration  AngularV  elocity V  ector.  mXAngularV  elocity 

AngularV  elocity V  ector.  mY  AngularV  elocity  AngularV  elocity V  ector.  mZ  AngularV  elocity 
Entityldentifier.mEntityNumber  Orientation.mPhi  Orientation.mPsi  Orientation. mTheta 
WorldLocation.mX  WorldLocation.mY  WorldLocation.mZ  VelocityVector.mXVelocity 

V  elocity V  ector.  mY  V  elocity  V  elocity  V  ector.mZ  V  elocity  mBodyLocation.mLat 

mBodyLocation.mLon  mBodyLocation.mAlt  mBody  VelocityVector.mXVelocity 

mBody  V  elocity V  ector.mY  V  elocity  mBody  V  elocity V  ector.mZ  V  elocity 

mBody AccelerationVector.mXAcceleration  mBodyAccelerationVector.mY Acceleration 
mBodyAccelerationVector.mZAcceleration  mBodyOrientation.mPhi  mBodyOrientation.mPsi 

mBodyOrientation.mThetaAbsoluteTimeStamp  ClassType  AccelerationVector.mXAcceleration 

AccelerationVector.mY Acceleration  AccelerationVector.mZAcceleration 

AngularV  elocity V  ector.  mXAngularV  elocity  AngularV  elocity V  ector.mY  AngularV  elocity 

AngularV elocity  Vector. mZAngularVelocity  Entityldentifier.mEntityNumber  Orientation.mPhi  Orientation.mPsi 
Orientation.  mTheta  WorldLocation.mX  WorldLocation.mY  WorldLocation.mZ 

V  elocity V  ector.  mXV  elocity  V  elocity  V  ector.  m YV  elocity  V  elocity  V  ector.mZ  V  elocity 

mBodyLocation.mLat  mBodyLocation.mLon  mBodyLocation.mAlt 

mBody  V  elocity V  ector.  mXV  elocity  mBody  V  elocity V  ector.  mYV  elocity 

mBody  V  elocity V  ector.mZ  V  elocity  mBodyAccelerationV  ector.  mXAcceleration 

mBody  AccelerationV ector.mY Acceleration  mBodyAccelerationVector.mZAcceleration  mBodyOrientation.mPhi 
mBodyOrientation.mPsi  mBodyOrientation.mTheta 

252157  0  5.25E-05  -0.000116771  -5.93E-05  -0.032856759  0.000127096 

0.000383347  60000  3.138170958  1.99312079  -0.455616295  1104191.308 

-2457472.554  5776931.999  -28.11977196  64.14194489  32.41397095 

1  17^080078  _1  1T8SH8171  1771£7S£Q£  77  1 AQ7707  O £78QAS77£ 


Figure  8.  An  example  of  the  decoded  RAP  file  for  one  entity. 
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field  type 

data  type 

units 

frame 

Time  Stamp 

ini 

JfS 

N/A 

Class  Type 

ini 

N/A 

N/A 

Object  Name 

hexadecimal  (4) 

N/A 

N/A 

Acceleration 

floatCT) 

m/s2 

NED 

Angular  Velocity 

float!  3) 

1/s 

body 

Entity  Identifier 

int 

N/A 

N/A 

float!  3) 

1 

NED 

Location 

float!  3) 

m 

“w.r.L  terrain  origin” 

Velocity 

float(3) 

m/s 

NED 

Marking  Data 

text 

N/A 

N/A 

Latitude 

float 

1 

w.r.L  Earth 

Longitude 

float 

1 

w.r.L  Earth 

Altitude 

float 

m 

w.r.L  Piarth 

Velocity 

iloat(3) 

m/s 

body 

Acceleration 

tloat(3) 

m/s2 

body 

(0^,9) 

float!  3) 

1 

body 

Figure  9  Fields  and  data-types  contained  in  the  RAP  data  files.  Data-types  with  parenthesis 

indicate  vectors  of  length  as  specified. 


6.2  NATO  STANAG  4586  Messages 

The  STANAG  4586  is  a  “Standardisation  Agreement”  developed  by  NATO  as  a 
means  for  producing  standard  interfaces  for  UAV  Control  Systems  (USC)  for  NATO 
UAV  interoperability.  It  consists  of  a  set  of  seventy  messages,  each  containing  several 
fields  of  information  with  a  time-stamp  used  for  bi-directional  communications 
between  a  UAV  and  a  GCS. 

As  with  the  RAP  data,  this  data  was  time-stamped  and  stored  in  a  file,  which  was  later 
processed  through  CAE  software  and  dumped  into  a  text  file.  Some  of  this  data 
overlaps  with  the  RAP  data. 

As  an  example,  STANAG  4586  message  #5  is  the  “Inertial  States”  and  contains, 
among  other  data  fields,  the  UAV  latitude,  longitude,  altitude,  speed,  acceleration, 
configuration.  STANAG  message  #1 1  is  the  “Vehicle  Steering  Command”  and  lists 
the  commanded  altitude,  speed,  and  heading  given  to  the  UAV  from  the  GCS.  Other 
important  STANAG  messages  are  the  “Vehicle  Operating  Mode  Command”  (#10) 
and  the  “Loiter  Configuration”  (#62).  A  full  listing  of  the  messages  and  fields  can  be 
found  in  the  Edition  2  of  the  STANAG  4586. 

An  example  of  a  decoded  STANAG  4586  data  file  is  provided  in  Figure  10.  There 
was  one  such  file  for  each  message  type,  for  each  mission. 
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AbsoluteTimeStamp;StanagType;StanagTimeStamp;mVehicleID;CUCSID;AltitudeCommandType;Com 
manded  Altitude ;  CommandedAltitudeRate  ;HeadingCommandT  ype ;  CommandedHeading ;  CommandedHe 
adingRate;CommandedAirspeed;SpeedType;Waypoint;BarometricPressure;AltitudeType;LoiterPositionL 
atitude;LoiterPositionLongitude 

438427;11;1087584838.827497;1 6843008 1;305419894;1;2000;0;1;1. 592069745063781 7;0;0;0;1;0;0;0. 8 
0047029137742798;-1. 153215378882174 

438626;  1 1 ;  1 087584839.00761 8;  1 6843008 1  ;3054 1 9894;  1  ;2000;0;  1 ;  1 .876675248 146057 1  ;0;0;0;  1  ;0;0;0.8 
0047029137742798;-1. 153215378882174 

438838;1 1;1087584839.247849;168430081;305419894;1;2000;0;1;2.09686279296875;0;0;0;1;0;0;0.800 
47029137742798;-1. 153215378882174 

439 126;1 1  ;1087584839.4878221;168430081;305419894;1;2000;0;1;2. 3561944961 547852;0;0;0;1;0;0;0. 
80047029137742798;-1. 153215378882174 

439342;1 1;1087584839. 6699381  ;168430081  ;305419894;1  ;2000;0;1;2. 709 1848850250244;0;0;0;1;0;0;0. 
80047029137742798;-1. 153215378882174 

439441  ;11;1087584839.7880659;168430081;305419894;1;2000;0;1;- 

3. 0221 6362953 18604;0;0;0;1;0;0;0. 80047029 137742798;-1. 1532 15378882 174 

439644;11;1087584840. 0283 141  ;1 68430081  ;305419894;1;2000;0;1;- 

2. 79282 16457366943;0;0;0;  1;0;0;0. 80047029 137742798;-1. 1532 15378882 174 

439845;11;1087584840.2075579;168430081;305419894;1;2000;0;1;- 

3. 0466408729553223;0;0;0;1;0;0;0. 80047029 137742798;-1. 1532 15378882 174 

440044;  1 1 ;  1 087584840.448 1 53 ;  1 6843008 1  ;3054 1 9894;  1  ;2000;0;  1 

3. 0466408729553223;0;0;0;1;0;0;0. 80047029 137742798;-!.  1532 15378882 174 


Figure  10.  Example  of  recorded  STANAG  4586  Message  Traffic 
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7.  Observation  /DEMO  Lab  used  in  the  Experiment 


The  main  laboratory  facilities  used  at  DRDC  Ottawa  included  the  UAV  Battle  Lab 
(Rm.  228)  and  the  ACCES  lab  (Rm.  222).  The  Advanced  Collaborative  Capability 
Engineering  System  (ACCES)  lab  is  a  state  of  the  art  Multi-Media  Lab  used  for  Live 
Demonstrations  and  VIP  Observation.  In  the  JSMARTS  Live  demonstration,  an 
attempt  was  made  to  provide  complete  coverage  of  the  distributed  experiment  from 
the  observation  site  to  allow  observers  to  view  all  aspects  of  the  experiment  from  one 
single  location,  thus  maximizing  situational  awareness  for  all.  An  html  page  was 
created  for  the  specific  purpose  of  easily  selecting  any  view  from  the  web  interface 
(see  Fig.  7).  The  observations  site  included: 

1 .  A  view  of  the  Synthetic  Tactical  Environment,  which  would  display  the 

current  status  of  the  synthetic  environment  as  seen  by  the  experiment  manager 
station. 

2.  Live  camera  feed  of  RTB  1  showed  the  RTB  operator  crew. 

3.  Live  Electro-Optical  (EO)  and  Infra-Red  (IR)  camera  video  feed  from 

RTB  1  displayed  the  sensor  views  as  seen  on  the  Ground  Control  Station 
Mission  Payload  Operator  (GCS-MPO)  station.  It  contained  a  map  of  the 
current  area  of  operation  and  an  IR  or  EO  sensor  capture.  This  is  refreshed 
every  10  seconds. 

4.  Operator  and  Mission  Crew  Voice  Communications:  All  voice 
communications  between  the  various  operators  and  mission  crew  were 
recorded  into  a  single  channel,  and  transmitted  live  to  the  observation  site  in  a 
live  real  media  format. 

5.  Live  Video  Feed  from  the  Griffon  Helicopter  Simulator:  During  the  actual 
demonstration,  some  pre-recorded  video  of  the  Griffon  simulator  taking  part  in 
a  mission  scenario  was  fed  into  the  ACCES  Lab,  since  the  live  feed  from 
Carleton  was  experiencing  technical  difficulties. 
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Figure  11:  The  WEB  interface  for  the  VIP  Observation/Demo  Lab.  From  this  html  page,  all  audio 
and  video  feeds  could  be  accessed  in  the  ACCES  Lab,  all  supported  by  FFSE’s  JSIMNet  network. 
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8.  Conclusions  and  future  work 


The  results  of  the  present  experiment  have  demonstrated  that  an  interoperable  HLA- 
based  distributed  simulation  federation  can  be  assembled  and  executed  over  a  non- 
dedicated,  unclassified,  VPN-encrypted  network  in  about  4  weeks.  Though  it  may 
sound  trivial  to  some,  rarely  has  the  GOC,  Industry  and  Academia  simulated  together 
in  Canada,  and  they  certainly  have  never  performed  such  an  initiative  in  such  a  short 
period  of  time.  It  is  also  interesting  to  highlight  that  since  such  a  simulation  could  be 
performed  in  this  amount  of  time,  this  initiative  was  never  a  project  or  a  program,  it 
was  nothing  more  than  an  initiative  that  simulationists  executed  as  a  JSMARTS 
concept. 

From  a  technical  perspective,  this  experiment  has  also  demonstrated  that  it  is  possible 
to  perform  a  distributed  simulation  using  different  FOMs  and  different  RTIs,  if  the 
team  is  using  a  FOM  Gateway  to  perform  the  re-mapping.  Using  the  GENESA  tool, 
the  team  members  were  able  to  avoid  any  development  time  associated  with  changing 
FOMs  and  acquiring  another  RTI.  Further,  additional  development  time,  including 
ensuring  perfect  data  correlation  was  cut  by  selecting  STRIVE  as  a  common  SE  tool. 

Though  it  is  still  early,  preliminary  data  seem  to  suggest  that  when  the  Tactical 
Aircrew  have  control  of  UAV  sensors,  in  a  Network  Centric  Warfare  context,  it  leads 
to  enhanced  Griffon  crew  performance  through  an  improved  tactical  effectiveness, 
increased  situational  awareness  and  decreased  workload.  Additional  studies  are 
required  to  confirm  this  finding. 

Finally,  it  is  possible  to  conclude  that  the  achievement  of  HLA  distributed  simulation 
with  GOC,  Academia  and  Industry  partners  will  lead  to  a  further  increment  in  critical 
mass  of  partners  using  simulation,  using  International  standards,  and  thus  enhancing 
the  Return  on  Investment  in  M&S.  Such  an  expansion  of  simulation  utilisation  with 
more  partners  joining  in,  each  with  their  own  SE  capability,  know-how,  assets,  etc., 
indicates  that  more  re-usability  will  be  available  to  the  Canadian  communities 
involved  in  any  aspect  of  simulation,  from  CD&E  to  Training  all  the  way  to  disposal 
of  any  system  of  capability.  Such  an  increase  in  critical  mass  of  Organizations 
utilizing  M&S  also  means  a  larger  Canadian  capability  to  participate  in  CD&E  and 
exploring  “what  if’  scenarios  of  any  kind.  This  includes  CBRN  threat  assessments  for 
Public  Security  partners  that  could  be  involved  a  Distributed  Simulation  prior  to  the 
Vancouver  Olympics  of  2010,  as  one  example. 
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List  of 

symbols/abbreviations/acronyms/initialisms 


ACCES 

Advanced  Collaborative  Capability  Engineering  System 

API 

Application  Programming  Interface 

AVO 

Air  Vehicle  Operator 

CD&E 

Concept  Development  and  Experimentation 

CF 

Canadian  Forces 

CFEC 

Canadian  Forces  Experiment  Centre 

CGF 

Computer  Generated  Forces 

COTS 

Commercial-Off-The-Shelf 

DACS 

Digital  Audio  Communications  System 

DAR 

Director  Aerospace  Requirements 

DIS 

Distributed  Interactive  Simulation 

DRDC 

Defence  Research  and  Development  Canada 

DND 

Department  of  National  Defence 

EO/IR 

Electro-Optical  and  Infra-Red  Sensor 

EOS 

Experimenter/Operator  Station 

FEDEP 

Federation  Development  and  Execution  Process 

FFSE 

Future  Forces  Synthetic  Environments 

FOM 

Federation  Object  Model 

GCS 

Ground  Control  Station 

GOC 

Government  of  Canada 

22 


DRDC  Ottawa  TM  2005-  101 


HAT 

Height  Above  Terrain 

HLA 

High  Level  Architecture 

HMD 

Hemet  Mounted  Display 

ICD 

Interface  Control  Document 

IG 

Image  Generation 

JSIMNet 

Joint  Simulation  Network,  FFSE 

JSMARTS 

Joint  Simulation,  Modeling  for  Material  Acquisition,  Requirements, 
Training,  and  Support 

M&S 

Modeling  and  Simulation 

MIF 

Mission  Information  Function 

MPO 

Mission  Payload  Operator 

NTS 

Networked  Tactical  Simulator 

NVG 

Night  Vision  Goggle 

OGD 

Other  Government  Department 

OTW 

Out-The- W  indow 

RAP 

Record  and  Playback 

RPR  FOM 

Real-time  Platform  Reference  Federation  Object  Model 

RTB 

Research  Test  Bed 

RTI 

Run  Time  Infrastructure 

SE 

Synthetic  Environment 

SMARRT 

Simulation  and  Modeling  for  Acquisition,  Requirements,  Rehearsal 
and  Training 

SME 

Subject  Matter  Expert 

STANAG 

Standardisation  Agreement  (NATO) 
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TAMSS 

TDP 

TSPI 

UAV 

WAN 

vc 

W5 


Tactical  Aviation  Mission  Systems  Simulation 

Technology  Demonstration  Program 

Time,  Space,  Position  Information 

Uninhabited  Aerial  Vehicle 

Wide  Area  Network 

UAV  velocity  vector 

wind  victor 

heading 

wind  heading 

standard  deviation 
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